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(54) Verfahren zum Konvertieren sich untersctieidender Datenformate 



(57) Der Austausch von Nachrichten Oder Daten 
zwischen, auf unterschiedlichen Prozessoren etnes 
Kommunikationssystems ablaufenden Programmen ist 
insofern problematisch, als daB unter Umstanden sich 
unterscheidende Datenformate, wie zum Be i spiel das 
Big-Endian-Format Oder das Little-Endian-Format, ver- 
wendet werden. Das erfindungsgemafce Verfahren 
schafft hier Abhilfe, indem bereits wahrend des Uber- 
setzungsvorganges der Quel (programme eine Konver- 
tierungsprozedur pro Datentyp generiert wird, die 
wahrend des spateren Ablauts der ProzeBe und Pro- 
gramme unmitlelbar vor dem Nachrichtenaustausch die 
Konvertierung der Datenformate steuert. 
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Beschreibung 

Die Erfindung betrifft ein Verfahren gemaB Oberbe- 
griff des Patentanspruchs 1. 

ZeitgemaBe Kommunikationssysteme sind als Mul- 
tiprozessorsysteme ausgebitdet. Dies bedeutet, da 3 
eine Vielzahl von Prozessoren die Steuerung der 
systeminternen Vorgange durchfOhren. In der Regel 
sind derartige Kommunikationssysteme als heterogene 
Systeme ausgebildet. Dies bedeutet, daB Prozessoren 
verschiedener Hersteller im Kommunikationssystem 
eingesetzt werden. Damit arbeiten aber diese Prozes- 
soren auch nach herstellerspezifischen Standards. So 
werden beispielsweise Daten von den einzelnen Pro- 
zessoren in unterschiedlichen Formaten im jeweils 
zugeordneten Speicher abgelegl Dies bedeutet 
solange keine Einschrankung des Betriebes, solange 
Programme, die in der Regel wahrend ihres Ablaufes 
jeweils einem Prozessor zugeodnet sind, diese Daten 
aus dern betreffenden Speicher auslesen.verarbeiten 
und wieder in den Speicher einschreiben, da in diesem 
Fall stets dasselbe Datenformat verwendet wird. Pro- 
bleme entstehen meist dann, wenn Nachrichten oder 
Daten zwischen Prozessoren bzw. auf diesen ablaufen- 
den Programrnen ausgetauscht werden. da hier gege- 
benenfalls diese Daten an die unterschiedlichen 
Datenformate angepaBt werden mussen. 

So werden beispielsweise Daten, die auf Prozesso- 
ren der Motorola-Familie verarbeitet werden, von diesen 
in einem LSB_HI-Format (Least Significant Byte at 
Highest Address), auch Big-Endian- Format genannt, 
abgelegt Im Gegensatz dazu werden Daten, die auf 
Prozessoren der Intel- Familie verarbeitet werden, von 
diesen in einem LSB_LO-Format (Least Significant 
Byte At Lowest Address),auch Little- Endian- Format 
genannt, abgelegt. Damit mussen nun im Fade eines 
Datenaustausches zwischen diesen beiden Prozessor- 
typen die Daten in entsprechender Weise konvertiert 
werden. 

Zur Losung derartiger Probleme hinsichtlich unter- 
schiedlicher Datenformate bei der ProzeBkommunika- 
tion in heterogenen Systemen wurde bisher ein 
spezielles Transferformat fur den Austausch von Nach- 
richten und Daten festgelegt. Dies bedeutet, daft gene- 
rell vor jedem Nachrichtenaustausch das prozess- 
or eigene Format in ein vorher festgelegt es, lediglich 
zum Zwecke des Austausches von Nachrichten verwen- 
detetes Obertragungsformat umgewandelt wird. 1st die 
Nachricht beim Zielprozessor angekommen.wird das 
Obertragungsformat in das dort verwendete prozessor- 
eigene Format zuruckverwandelt. Zu diesem Zweck 
wird beim Stand der Technik eine Bibliothek zur VerfG- 
gung ge steltt, die Konvertierungsfunktionen fur die 
Basisdatentypen derjeweiligen Programmiersprache 
enthait. Mit Hilfe dieser Formatkonvertierungen kOnnen 
dann die Clbertragungsformate beim Austausch von 
Nachrichten zwischen Prozessoren festgelegt werden. 

Weiterhin kOnnen bei verschiedenen Programmier- 
sprachen wie beispielsweise CHILL vom Erttwickler der 



Applikationssoftware Datenformate festgelegt werden, 
unter denen Daten abgespeichert werden. Diese Ver- 
haltnisse sind in "Language Solution for Mixed Data 
Formats. Mark Clark. G. Walter, fourth CHILL Confe- 

s rence. Munchen 29.9. - 2.10. 1986" dargelegt. 

Problematisch an einer derartigen Vorgehensweise 
ist. daB die durch den Austausch von Nachrichten mit- 
einander kommunizierenden Programme jeweils selbst 
fur die Konvertierung der auszutauschenden Nachrich- 

10 ten zwischen prozessoreigenem Datenformat und 
Transferformat verantwortlich sind. Damit mussen aber 
alle benotigten Format-Konvertierungen vom Entwickter 
der Applikationssoftware bei der Codierung des jeweili- 
gen Programmes explizit programmiert werden. Insbe- 

15 sondere sind Konvertierungen komplexer Datentypen 
(Strukuren, Arrays) explizit auf die durch cfie Biblio- 
theksfunktionen unterstutzten Konvertierungen der 
Basisdatentypen abzubilden. Damit ist zwangslaufig 
sowohl ein erhOhter Entwicklungsaufwand als auch eine 

20 zusatzliche Fehlerquelle verbunden. Weiterhin besteht 
bei strikter Anwendungn dieser Technik das Problem, 
daft auch beim Verse nd en von Nachrichten zwischen 
Programrnen, die auf Prozessoren mit ein- und demsel- 
ben Datenformats ablaufen, die Konvertierungen vom 

25 prozessoreigenen Datenformat des Quellenprozessors 
in das Obertragungsformat und aus dem Obertragungs- 
format in das prozessoreigene Datenformat des Ziel- 
prozessors erfolgen. Dadurch wird die Dynamik des 
Systems beeintrachtigt. 

30 Der Erfindung liegt die Aufgabe zugrunde, einen 
Weg aufzuzeigen, wie die Konvertierung von Datenfor- 
maten beim Austausch von Nachrichten oder Daten 
zwischen Prozessoren, in denen jeweils unterschiedli- 
che Datenformate verwendet werden, ohne einen 

35 Dynamikverlust des Systems bei reduzierter Fehleran- 
failigkeit gestaltet werden kann. 

Vorteilhaft an der Erfindung ist t da6 bereits wah- 
rend des Ubersetzungsvorgangs der Quellprogramme 
automatisch die fur die Konvertierung der Daten zwi- 

40 schen den Formaten notigen Prozeduren bereitgestellt 
werden. Dies wird erreicht, indem das Ubersetzungs- 
programm nach MaBgabe der in den Quellprogrammen 
verwendet en Datentypen Konvertierungsprozeduren 
wahrend des Ubersetzungslaufes erzeugt die dann 

45 wahrend des spateren Ablaufs der ubersetzten Pro- 
gramme vor dem Nachrichtenaustausch aufgerufen 
werden. Damit ist der Vorteil verbunden, daB der Ent- 
wickler keinerlei explizite Vorsorge fur die Konvertierung 
der Daten in der Applikationssoftware mehr vornehmen 

so muB. Damit entfalit neben dem erhGhten Entwicklungs- 
aufwand auch diese zusatzliche Fehlerquelle. 

Weitere Ausgestaltungen der Erfindung sind in den 
Unteranspruchen gegeben: 

GemaB Anspruch 2 ist vorgesehen, daB die Kon- 

55 vertierungsprozedur als Sourcecode generiert wird. der 
in einem gesonderten Ubersetzungslauf in den ablauf- 
fahigen Objektcode uberfuhrt wird. 

GemaB Anspruch 3 ist vorgesehen.daB bei mehr- 
maligem Auftreten desgleichen Datentyps fur die zu 
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uberfuhrenden Daten in einem Programm lediglich eine 
Konvertierungsprozedur generiert wird. Damit ist der 
Vorteil der Einsparung von Zeit bei der Ubersetztung 
des Quetlprogramms und von Speicherplatz verbunden. 

GemaB Anspruch 4 ist vorgesehen, daB im Falle, 
daB Daten zwischen Prozessoren mit gleichem Daten- 
format ausgetauscht werden, keine Konvertierungspro- 
zedur generiert wird. Dies wird durch die explizite 
Markierung der entsprechenden Datentypen im Quell- 
programm mit dem passenden Datenformat erzwun- 
gen. Damit ist der Vorteil einer erhChten Dynamik des 
Systems verbunden. 

Die Erf indung wird im folgenden anhand eines Aus- 
fuhrungsbeispiels nflher eriautert. 

Es zeigen: 

Figur 1 die im Kommunikationssystem verwende- 
ten unterschiedlichen Datenformate am 
Beispiel des Basisdatentyps INTEGER 

Figur 2 das erfindungsgemaBe Verfahren. 

Figur 1 zeigt sich unterscheidende Datenformate, 
wie sie von den Prozessoren eines Kommunikationssy- 
stems beim Abspeichern verwendet werden. Dabei ist 
gemaB Fig.la das Big-Endian-Format aufgezeigt. Bei- 
spielhaft sind hier vier Bytes, namlich Byte 0. Byte 1. 
Byte 2, Byte 3 dargestellt. Jedes Byte weist jeweils acht 
Bit auf. Die Signrf ikanz der Bits wird beginnend mit Bit 0 
von Byte 3 in aufsteigender Reihenfolge bis zu Bit 7 von 
Byte 0 def iniert. Als Beispiel ist weiterhin aufgezeigt, wie 
die dezimale Zahl 1 in diesem Format darstellbar ist. Sie 
wird realisiert, indem das niederwertigste Bit. namlich 
Bit 0 des Byte 3 gesetzt wird. 

GemaB Fig. 1b ist das Little-Endian-Format aufge- 
zeigt. Hier ist die Signifikanz der Bits in der dort aufge- 
zeigten Reihenfolge def iniert. Als Beispiel wird die 
dezimale Zahl 1 definiert. indem das niederwertigste 
Bit. namlich Bit 0 des Byte 0 gesetzt wird. Aus diesem 
Beispiel ergibt sich die unterschiedliche Definition bei- 
der Datenformate, sowie die Notwendigkeit einer 
Anpassung beider Datenformate beim Datenaustausch. 

GemaG Fig. 2 wird das erfindungsgemaBe Verfah- 
ren erlautert Dabei wird davon ausgegangen. da 3 die 
Konvertierungsvorgange automatisch von einem Uber- 
setzungsprogramm COMP wahrend des Ubersetzungs- 
vorgangs gesteuert werden. Somit muB wahrend der 
Codierungsphase keinerlei Vorsorge getroffen werden, 
wie und in welcher Weise die Konvertierung der Daten- 
formate erfolgen soli. Weiterhin wird davon ausgegan- 
gen. daB ein zu ubersetzendes Programm P sich 
unterscheidende Datentypen aufweist. Beispiel haft sol- 
len dies die Datentypen D 1( D 2 . und D 3 sein. Fur das 
erfindungsgemaBe Verfahren relevant sind komplexere 
Datentypen wie Strukturen oder Felder (Arrays), die es 
zu konvertieren gilt. Weiterhin wird in vorliegendem 
Ausfuhrungsbeispiel davon ausgegangen, daft ein 
Datentyp, namlich der Datentyp D 1t im Programm P 
mehrmals auftritt. 



Wahrend des Gbersetzungsvorgangs werden unter 
der Steuerung des Ubersetzungsprogramms COMP die 
Stellen im Code des Programms P, an denen Nachrich- 
ten zu anderen Programmen wahrend des spateren 

5 Ablauts gesteuert werden speziell behandelt. Es wird 
der Datentyp der Nachricht ermittelt, und im folgenden 
eine fur die Oberfuhrung dieses Datentyps in das 
Datenformat des Zielprozessors adequate Konvertie- 
rungsprozedur generiert. GemaB Fig.2 ist dies fur den 

to Datentyp D n die Konvertierungsprozedur KON v Die. 
Prozedur selbst wird im Sourcecode unter einem defi- 
nierten Prozedur namen abgelegt. AnschlieBend wird 
vor dem den Nachrichtenaustausch bewerkstelligenden 
Befehl der Aufruf dieser Konvertierungsprozedur einge- 

15 tragen. Im folgenden tritt der Datentyp D<, jedoch noch 
zweimal auf. Beim erneuten Auftreten dieses Datentyps 
als Nachricht wird keine erneute Generierung der Kon- 
vertierungsprozedur KON, vorgenommen. Lediglich der 
Prozeduraufruf wird an den betreffenden Stellen einge- 

20 fOgt. 

GemaB Fig. 2 treten im folgenden die Datentypen 
D 2 , D 3 als Nachrichten auf. Insofern mussen nun auch 
weitere, sich von der Konvertierungsprozedur KOI^ . 
unterscheidende Konvertierungsprozeduren generiert 

25 werden. In vorliegendem Ausfuhrungsbeispiel sollen 
dies die Konvertierungsprozeduren KON 2 . KON 3 sein. 
Die Konvertierungsprozedur wird also durch den Daten- 
typ def iniert. Dem Datentyp D 2 wird somit die Konvertie- 
rungsprozedur KON 2 und dem Datentyp D 3 die 

30 Konvertierungsprozedur D 3 zugeordnet. 

Beim spateren Ablaut des in den Objektcode uber- 
fOhrten Programmes P werden somit unmittelbar vor 
dem Nachrichtenaustausch Aufrufe der betreffenden 
Konvertierungsprozeduren durchgefuhrt. Damit werden 

35 die zu ubertragenden Daten in diejweiligen Datenfor- 
mate des Zielprozessors umgewandelt. 

In einer Ausgestaltung der Erf indung wird vorgese- 
hen, daB fur die Nachrichten, die zwischen ProzeBen 
ausgetauscht werden, die dasselbe Datenformat ver- 

40 wenden, vom Ubersetzungsprogramm COMP keine 
Konvertierungsrozedur generiert wird. 

Das vorstehend geschilderte Ausfuhrungsbeispiel 
bescheibt den Nachrichtenaustausch zwischen Prozes- 
soren mit sich unterscheidenden Formaten zum 

45 Abspeichern von Daten. Die Erf indung ist jedoch nicht 
auf dieses Ausfuhrungsbeispiel beschr&nkt. 

In einer weiteren Ausgestaltung wird vorgesehen, 
daB generell unterschiedliche Datenformate in einem 
Programm verwendet werden kOnnen. So lassen einige 

so Programmiesprachen wie z.B. CHILL die explizite 
Angabe eines Datenformates durch den Programmierer 
zu. Dieses durch den Programmierer erzwungene For- 
mat kann sich durchaus von den prozessoretgenen For- 
maten unterscheiden. Wahrend des Ubersetzungs- 

55 vorganges werden dann in oben angesprochenen 
Weise Konvertierungsprozeduren generiert und aufge- 
rufen. 
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Patentanspruche 

1 . Verfahren zum Konvertieren sich unterscheidender 
Datenformate, mit Programmer! (P), die als Ergeb- 
nis eines durch ein Ubersetzungsprogramm 5 
(COMP) gesteuerten Gbersetzungsvorgang in 
einen ablauffahigen Objektcode uberfuhrbar sind, 
und die gegebenenfalls unterschiedliche Datenty- 
pen aufweisende Daten bearbeiten, wobei letztere 
von einem ersten Format in ein zweites Format to 
uberfuhrbar sind 

dadurch gekennzeichnet, 
dafc unter der Steuerung des Gbersetzungspro- 
gramms (COMP) beim Gbersetzungsvorgang der 
Datentyp der zu uberfuhrenden Daten ermittett is 
wird, woraufhtn eine, diesem Datentyp adequate 
Konvertierungsprozedur (KON v ..KON 3 ) generiert 
wird, und dem den Gberfuhrungsvorgang bewerk- 
stelligenden Befehl ein Aufruf der betreffenden 
Konvertierungsprozedur (KON-^KON^vorange- 20 
stellt wird. 

2. Verfahren nach Anspruch 1 
dadurch gekennzeichnet, 

da8 Konvertierungsprozedur (KON^^KO^) ats 25 
Sourcecode generiert wird, der in einem gesonder- 
ten Gbersetzungslauf in den ablauffahigen Objekt- 
code Oberfiihrt wird. 

3. Verfahren nach 1 Oder 2. 30 
dadurch gekennzeichnet, 

daft bei mehrmaligem Auftreten desgleichen 
Datentyps fur die zu uberfuhrenden Daten in einem 
Programm (P) lediglich eine Konvertierungsproze- 
dur generiert wird. 35 

4. Verfahren nach Anspruch 1 bis 3, 
dadurch gekennzeichnet, 

daft im Fatle, daB Daten zwischen Prozessoren mit 
gleichem Datenformat ausgetauscht werden, keine 40 
Konvertierungsprozedur generiert wird. 
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FIG 1b 
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FIG 2 
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